This chapter contains general overview information about the Cisco® Mobile Video Gateway, including:
|
•
|
|
•
|
System Management Cards (SMCs): Provide full system control and management of all cards within the ASR 5000. Up to two SMCs can be installed; one active, one redundant.
|
|
•
|
Packet Services Cards (PSC2s): Provide high-speed, multi-threaded PDP context processing capabilities for 2.5G, 3G, and 4G services. Up to 14 PSC2s can be installed, allowing for multiple active and/or redundant cards.
|
|
•
|
Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SMCs, SPIOs provide connectivity for local and remote management and for central office alarms. Up to two SPIOs can be installed; one active, one redundant.
|
|
•
|
Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind the PSC2s, these cards provide the physical interfaces to elements in the operator’s network. Up to 26 line cards should be installed for a fully loaded system with 13 active PSC2s, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSC2s do not require line cards.
|
|
•
|
Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100 or Ethernet 1000 line cards and every PSC2 in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSC2s.
|
Additional information pertaining to each of the application and line cards required to support wireless data services is located in the “Hardware Platform Overview” chapter of the Product Overview Guide.
For more information about the Cisco P-GW and its connectivity to related network elements, see the Packet Data Network Gateway Administration Guide.
For more information about the Cisco GGSN and its connectivity to related network elements, see the Gateway GPRS Support Node Administration Guide.
For more information about the Cisco HA and its connectivity to related network elements, see the Home Agent Administration Guide.
For more information about Enhanced Charging Services on the ASR 5000, see the Enhanced Charging Services Administration Guide.
|
•
|
x-forwarded-dest-addr-port: The IPv4 destination address and TCP port number of the OS.
|
|
•
|
x-adaptation-profile-index: The index number of the video quality profile for the CAE to use to select the level of video quality for adaptation.
|
|
•
|
x-forwarded-dest-addr-port: The IPv4 destination address and TCP port number of the OS.
|
|
•
|
x-adaptation-profile-index: The index number of the video quality profile for the CAE to use to select the level of video quality for adaptation.
|
When sending HTTP video requests to the OS for video content, the CAE inserts the following x-header: x-forwarded-for: The IPv4 address of the subscriber UE.
In this software release, the video policy includes a CLI charging-action command option for specifying a suggested maximum bit rate value for video. This value, specified in bits per second (bps), is used by two of the video optimization modules on the Mobile Video Gateway, the video pacing module and the video transrater module.
|
•
|
PCRF via the Gx interface: Acting as a RADIUS endpoint, the Mobile Video Gateway can obtain the video policy for a subscriber using the Gx interface to the PCRF. With this method, the Charging-Rule-Name attribute received in the Charging-Rule-Install AVP in the CCA-I message contains a rule definition name that maps to the video policy. This rule definition is part of the rulebase assigned to the subscriber. The Mobile Video Gateway can assign the rulebase to the subscriber through a static configuration at the subscriber or APN level, or obtained from the RADIUS server in an Access-Accept message.
|
|
•
|
RADIUS Server via the RADIUS interface: In the absence of a Gx interface, the Mobile Video Gateway can obtain the video policy from the RADIUS server through the Access-Accept message. With this method, the Mobile Video Gateway applies the RuleBase-Name AVP in the Access-Accept message to the subscriber, and one of the rule definitions in the configured rulebase selected in this manner maps to the video policy. Note that one rulebase gets associated with one level of subscriber entitlement (GOLD_RULEBASE, for example).
|
|
•
|
Static assignment at the subscriber or APN level: The Mobile Video Gateway can assign a video policy by assigning a rulebase at the subscriber or APN level, so that one of the rule definitions in the configured rulebase maps to the video policy. As in the RADIUS server method, one rulebase gets associated with one level of subscriber entitlement.
|
During configuration, a rulebase is defined for each subscriber or APN and contains multiple rule definitions. When obtaining the video policy from the PCRF via the Gx interface, and when obtaining the video policy via the Charging-Rule-Install AVP, the Mobile Video Gateway enables a particular rule definition when a rule definition name matches the received Charging-Rule-Name attribute. This is achieved by using the dynamic-only option in the action priority command when configuring the rulebases. When obtaining the video policy via the RuleBase-Name AVP, note that there can be one and only one rule definition and its corresponding charging action associated with a video policy.
For configuration instructions and sample configurations, see Chapter 2. For detailed instructions for configuring the Gx interface on the Cisco P-GW, see the Packet Data Network Gateway Administration Guide.
|
•
|
Pacing Start Trigger: The pacing start trigger is part of the Active Charging Service for video pacing. When a rule definition in the Active Charging Service identifies a packet flow as a video flow, and the corresponding charging action for video pacing is enabled, the pacing start trigger invokes video pacing enforcement for the video flow. It sets the video bit rate and initial burst size from the subscriber policy, which is configured for subscribers in the source context as part of the active charging rulebase. It then becomes dormant.
|
|
•
|
Video Pacing Enforcement: After the initial burst of video content, the video pacing enforcement function sets the optimal video download rate for the incoming downlink packets using a token bucket algorithm. Video pacing occurs based on the settings configured via CLI command options.
|
|
•
|
Video Rate Determination: The video rate determination function is a software algorithm that examines the initial HTTP RESPONSE packets and video metadata packets to determine the encoded bit rate of the video. It examines the HTTP RESPONSE headers to determine the content length of the video in total bytes as well as the total video playback duration, and then calculates the average video bit rate as: (Content length/Video playback duration). It then triggers the video pacing enforcement function to enforce the new average bit rate when the next downlink packet is received.
|
|
•
|
CLI Command Options: The video pacing feature includes a set of CLI command options for the Active Charging Service charging-action command.
|
For a description of these command options, see the Command Line Interface Reference.
|
•
|
Video Pacing and the CAE: The video pacing feature is an independent software module and has no interface with the Cisco CAE. It performs its function in the same way whether a video is downloaded from the OS or from the CAE. The CAE is an optional component of the Cisco Mobile Videoscape.
|
|
•
|
Video Pacing and the TCP Proxy: The video pacing feature can be configured to work with or without the TCP proxy feature with no change in its function.
|
|
•
|
Video Pacing and Traffic Performance Optimization: The traffic performance optimization feature works over the interface on the client side of the TCP proxy. It handles re-transmission, TCP window size adjustment, and so on. Video pacing works over the interface on the video server side of the TCP proxy, and works independent of traffic performance optimization.
|
|
•
|
Video Pacing and Transrating: The video pacing feature works independent of transrating. Transrating is a mobile video feature that reduces the encoded bit rates by adjusting video encoding.
|
The dynamic inline transrating feature enforces a target bit rate reduction that is configured via a charging-action command option. This target bit rate reduction is specified as a percentage of the input bit rate of a video flow—a 10 percent target rate reduction, for example.
|
•
|
Selection scenario 1: When the TCP link monitoring feature’s bandwidth estimation is 0 or is greater than the incoming video data rate, dynamic inline transrating does not get applied to the current or next-to-be-processed epoch.
|
|
•
|
Selection scenario 2: When the TCP link monitoring feature’s bandwidth estimation is greater that the suggested maximum bit rate from the video policy and less than the incoming video data rate, the target rate reduction configured via the charging-action command option is selected.
|
|
•
|
Selection scenario 3: When the current network bandwidth is not sufficient to accommodate the operator’s configured target rate reduction, the selection algorithm lowers the configured rate by a delta, where the delta is the additional bandwidth necessary to provide sufficient EoS (Experience of Service) to the subscriber. The limit to this delta is the hard limit derived from the incoming video data rate.
|
The TCP proxy can be dynamically enabled based on Active Charging Service rule definitions. For information about the dynamically-enabled TCP proxy, including configuration instructions, see the Enhanced Charging Services Administration Guide.
For information about traffic performance optimization, including configuration instructions, see the Traffic Performance Optimization Administration Guide.
|
•
|
Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated, then generated and/or sent again at the end of the polling interval.
|
|
•
|
Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated, then generated and/or sent again at the end of the polling interval.
|
|
•
|
SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values. Generation of specific traps can be enabled or disabled on the chassis, ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.
|
|
•
|
Logs: The system provides a facility for which active and event logs can be generated. As with other system facilities, logs are generated messages pertaining to the condition of a monitored value and are generated with a severity level of WARNING. Logs are supported in both the Alert and the Alarm models.
|
|
•
|
Alarm System: High threshold alarms generated within the specified polling interval are considered outstanding until a condition no longer exists or a condition clear alarm is generated. Outstanding alarms are reported to the system’s alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.
|
For more information about threshold crossing alert configuration, see the Thresholding Configuration Guide.
|
•
|
Total size of the video file (the HTTP content length): This is the size given in the HTTP RESPONSE header for the video file, represented in bytes.
|
|
•
|
Total duration of the video clip: This is the video play duration identified from the video metadata, represented in seconds. If the mobile video statistics feature cannot get this information from the metadata (due to non-standard metadata formatting, etc.), this field shows 0.
|
|
•
|
Total bytes sent to the UE: This is the payload data bytes (excluding TCP/IP headers) permitted to be sent towards the UE. Note that this counter includes end-to-end (TCP) retransmissions.
|
|
•
|
Total duration that the video object is on: This is the time it takes for the UE to finish downloading the video, which is from the creation of the first flow to the deletion of the last flow comprising this video.
|
|
•
|
Total number of TCP flows used to download the video: The total count of TCP sessions used for this video object.
|
|
•
|
Video delivery rate: Total bytes sent to the UE/Total duration that the video object is on. This is the average bit rate of the video payload bytes being delivered to the UE, represented in bps.
|
|
•
|
Percentage of video download: Total bytes sent to the UE/Total size of the video file. This is the percentage of the video file that the user actually downloaded. The number reflects whether users tend to watch the entire video or only a small part of it. Note that since “Total bytes sent to the UE” includes retransmissions, this number can be larger than 100%.
|
|
•
|
Video encoding bit rate: Total size of the video file/Total duration of the video clip. This is the average video encoding bit rate, represented in bps.
|
|
•
|
UE device type: Apple iOS devices (iPhone, iPad®, and iPod®), Android™ devices, laptops, and other devices.
|
|
•
|
Radio access type: 2G, 3G, 4G-LTE, CDMA, HSPA, WLAN, and other types.
|
|
•
|
Video container type: flv/f4v, mp4 (includes related types such as m4v, 3gp, 3g2, and mov), and other types.
|
For configuration instructions, see Chapter 2. For information about the variables in the MVS schema, see the Statistics and Counters Reference.
|
•
|
System: Provides system-level statistics.
|
|
•
|
Card: Provides card-level statistics.
|
|
•
|
Port: Provides port-level statistics.
|
|
•
|
MVS: Provides statistics to support the Mobile Videoscape (MVS).
|
